In software development a software application is often designed and built in a modular fashion. The application is divided into multiple modules known as software methods, each providing a particular function of the application. A method includes a block of program code comprising a series of instructions which can be executed in a computer system. A method is executed by loading the program code into a memory of the computer system and executing the program code in a processor of the computer system.
A first method in execution usually calls a second method, this involves suspending the execution of the first method and commencing the execution of the second method. The second method subsequently executes in the processor of the computer system. Once the execution of the second method has completed it is terminated and the first method resumes execution. The termination of the execution of the second method and the resumption of the execution of the first method is known as a method return. During the execution of the software application methods may invoke many other methods in this way, and an invoked method may invoke further methods and so on.
A data structure known as a call stack is used to store all methods in execution in the computer memory at a given point in time. The call stack is an implementation of a stack data structure which stores a series of data elements in a sequential manner as is well known in the art. Elements of a stack are always added and removed to and from the top of the stack. The call stack contains methods in execution in the application. Methods are added to the top of the call stack when they are invoked, and removed from the top of the call stack when they return. The first method invoked for an application is typically placed at the bottom of a new call stack, known as the base of the call stack. The call stack grows and shrinks as methods are added (called) and removed (returned). Each method in the call stack can be referenced by it's position in the call stack as an offset from the base of the stack. As methods are added to the top of the call stack the stack grows and the method at the top of the call stack is said to be “deeper” in the stack. Similarly, methods near the base of the call stack are said to be “shallow” in the stack.
In addition to providing the functionality for the application, methods may also generate data at run-time known as trace data. Trace data may include information such as time stamps, variable contents, details of threads and input and output operations. Once generated, trace data from the execution of an application is typically stored to a data store (such as a hard disk drive). Trace data is subsequently used by software analysts or software analysis tools to, for example, model the application in operation in order to make improvements to the application in execution. The analysis involves an examination of trace data for a specific subset of all the methods in an application, known as the “methods of interest”. Ideally this analysis is done at runtime so that changes can be made to the execution of the application in response to findings of the analysis.
Exactly which methods in the application are the methods of interest depends on the purpose of the analysis. For example, analysis directed to improving the performance of an application may focus on those methods which take the most time to execute. The methods of interest are not usually found deep in a call stack, as the deeper methods in a call stack often implement highly detailed logic. Additionally, the methods of interest are not usually found near the base of the call stack, as these methods are often high-level structural methods with little implementation detail. Rather, the methods of interest typically fall somewhere between the shallowest methods in the call stack and the deepest methods in the call stack.
If too many methods are traced an unacceptably large volume of trace data will be produced. The trace data for the methods of interest is mixed with extraneous trace data relating to other methods. A software developer or analysis tool would then be required to identify and separate the trace data for the methods of interest from the extraneous trace data.
One known solution to limit the quantity of trace data generated when tracing an application is to generate trace data only for those methods with an offset from the base of the call stack which does not exceed a predefined maximum trace offset. For example, if the maximum trace offset is four stack positions from the base of the call stack, this known solution limits trace data generation to those methods which are offset by no more than four stack positions from the base of the call stack. While this prevents the generation of extraneous trace data for deep method invocations, trace data will still be generated for shallow methods which do not exceed the maximum trace offset. Therefore, the present state of the art often still produces too much extraneous trace data. This makes analysis of such trace data at runtime impractical.